ci: dedup PyPI publish trigger and bump actions to Node 24#31
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 33 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughGitHub Actions workflows (ci.yml, publish.yml, test.yml) are updated to use newer major versions of checkout, setup-python, cache, codecov, upload-artifact, and download-artifact actions. The publish workflow's triggers and job conditions are restricted to version tag pushes and manual dispatch, with skip-existing added for PyPI publishing. ChangesCI/CD Workflow Upgrades
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Trigger as Push/Dispatch
participant Publish as Publish Workflow
participant Build as Build Job
participant PyPI as PyPI Publish
participant TestPyPI as TestPyPI Publish
Trigger->>Publish: push tag / workflow_dispatch
Publish->>Build: run checkout, setup, tests, build
Build->>Publish: upload artifact
alt ref starts with refs/tags/
Publish->>PyPI: download artifact, publish (skip-existing)
else manual non-tag dispatch
Publish->>TestPyPI: download artifact, publish
end
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (3)
.github/workflows/publish.yml (1)
18-18: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winAdd
persist-credentials: falseto both checkout steps.Same
artipackedflag as inci.yml/test.yml. This job additionally does a full-history checkout (fetch-depth: 0), so the persisted credential window covers more of the job.Also applies to: 53-55
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/publish.yml at line 18, The checkout steps in this workflow are still persisting credentials; update both uses of actions/checkout in the publish job to set persist-credentials to false, matching the ci.yml and test.yml pattern. Apply this to both checkout entries in the job, including the full-history checkout that uses fetch-depth: 0, so the credentials are not left available for the rest of the workflow.Source: Linters/SAST tools
.github/workflows/ci.yml (1)
18-18: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winConsider
persist-credentials: falseon checkout steps.Both checkout steps (test job and build job) rely on default credential persistence. Static analysis flags this as
artipacked; a compromised transitive dependency pulled in by the subsequentpip install -e .step could read the persisted git token from disk. Neither job appears to need push/write access here.🔒 Suggested fix
- uses: actions/checkout@v5 + with: + persist-credentials: falseApply the same change to the build job's checkout (Line 81).
Also applies to: 81-81
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml at line 18, Add persist-credentials: false to both actions/checkout@v5 steps in the CI workflow so the jobs do not leave a writable git token on disk. Update the checkout used in the test job and the matching checkout in the build job, since neither job needs repo write access and the later pip install -e . step should not be able to read persisted credentials.Source: Linters/SAST tools
.github/workflows/test.yml (1)
17-17: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winSame
persist-credentialshardening applies here.See the equivalent comment in
ci.yml— addpersist-credentials: falseto this checkout step as well.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/test.yml at line 17, The checkout step in the workflow still uses the default persisted Git credentials, so harden this `actions/checkout` usage by setting `persist-credentials: false` on the same step. Update the checkout configuration in this workflow to match the hardened pattern used elsewhere, keeping the change localized to the `actions/checkout` entry.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/ci.yml:
- Line 18: Add persist-credentials: false to both actions/checkout@v5 steps in
the CI workflow so the jobs do not leave a writable git token on disk. Update
the checkout used in the test job and the matching checkout in the build job,
since neither job needs repo write access and the later pip install -e . step
should not be able to read persisted credentials.
In @.github/workflows/publish.yml:
- Line 18: The checkout steps in this workflow are still persisting credentials;
update both uses of actions/checkout in the publish job to set
persist-credentials to false, matching the ci.yml and test.yml pattern. Apply
this to both checkout entries in the job, including the full-history checkout
that uses fetch-depth: 0, so the credentials are not left available for the rest
of the workflow.
In @.github/workflows/test.yml:
- Line 17: The checkout step in the workflow still uses the default persisted
Git credentials, so harden this `actions/checkout` usage by setting
`persist-credentials: false` on the same step. Update the checkout configuration
in this workflow to match the hardened pattern used elsewhere, keeping the
change localized to the `actions/checkout` entry.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f75620ed-c442-4e89-811b-f92654ac3604
📒 Files selected for processing (3)
.github/workflows/ci.yml.github/workflows/publish.yml.github/workflows/test.yml
- Fix every GitHub Release showing a failed "Build and Publish to PyPI" run: the workflow fired on both `push: tags` and `release: published`, so two publish jobs raced and the loser hit `400 File already exists`. Drop the `release` trigger (a published Release still creates the tag, so `push: tags` covers both the Release and bare-tag flows) and add `skip-existing: true` as a re-run guard. - Clear the Node 20 runtime deprecation warnings across all three workflows by bumping each action to its first Node 24 major: checkout v5, setup-python v6, cache v6, upload-artifact v6, download-artifact v7. - Update codecov-action v3 to v5 with its breaking input rename `file:` to `files:` (v5 is a composite action, no Node runtime). - Restrict the TestPyPI job to manual non-tag dispatch only, and set `persist-credentials: false` on every checkout so no writable git token is left on disk (none of these jobs push).
hampsterx
force-pushed
the
ci/workflows-node24-publish-dedup
branch
from
9e8970a to
8547ff2
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
Summary
push: tagsandrelease: published; a published Release creates the tag, so both triggers launched a publish job, they raced, and the loser failed with400 File already exists. Drop thereleasetrigger and keeppush: tags(a published Release still creates the tag, and bare tag pushes like 1.4.1 keep working), plus addskip-existing: trueas a re-run guard.checkoutv5,setup-pythonv6,cachev6,upload-artifactv6,download-artifactv7.codecov-actionv3 → v5 with its breaking input renamefile:→files:(v5 is a composite action, no Node runtime).publish-test(TestPyPI) job to manual, non-tagworkflow_dispatchonly, removing a dead branch-push clause and preventing a manual dispatch on a tag ref from publishing to both PyPI and TestPyPI.actions/checkoutstep withpersist-credentials: falseso no writable git token is left on disk. None of these jobs push (the CI black-format step commits locally only), so nothing relies on the persisted credential.Review
Internal: 1 auto-fixed (dead TestPyPI clause). External (Codex + Kimi-agentic): 1 applied (dispatch-on-tag double-publish guard), no blocking issues. CodeRabbit: 3
persist-credentialsnitpicks, all applied.Changes
Test plan
yaml.safe_load)node24(or composite) via itsaction.ymlruns.using400)Backwards compatibility
No package or API changes. CI/release infrastructure only. Existing release flow is unchanged for maintainers: publishing a GitHub Release (or pushing a version tag) still publishes to PyPI, now via a single run instead of a racing pair.